S7 property getters whose return type is another `#[miniextendr(s7)]`
class previously fell through `rust_type_to_s7_class` and were emitted
without a `class = …` constraint, so S7 implicitly widened them to
`class_any`. With `#155` / `#192` there's already an established
pattern for cross-crate class-name resolution via the CLASS_REF
placeholder — this change reuses it for S7 properties.

When a getter returns a bare, ungeneric, PascalCase single-segment
type (i.e. what a user-defined class looks like), the macro now emits
`.__MX_CLASS_REF_<Type>__` as the class constraint. At cdylib
write-time the existing resolver in `write_r_wrappers_to_file` swaps
in the R-visible class name recorded by the referenced impl block's
`MX_CLASS_NAMES` entry — so `class = "Override"` on the target is
honored, and cross-crate class hierarchies Just Work.

Verified against a new `S7PropOuter`/`S7PropInner` pair in
`rpkg/src/rust/s7_tests.rs`:

  inner = S7::new_property(class = S7PropInner, ...)

instead of the prior `class_any`. The existing CLASS_REF
unresolved-fallback path (emit bare Rust name + compile warning)
gives users a clear diagnostic when a getter returns an unregistered
type — one more place where that warning lands, and the R side will
then error at load time with `object '…' not found`, which is the
correct signal.

Matching criteria are narrow on purpose — only PascalCase + single
segment + no generics + no `::` — so primitives and type params keep
falling through to `None` (macro omits the constraint, S7 uses
`class_any`, old behavior). Types like `SEXP`, `PathBuf`, or
`ExternalPtr` in a getter return still trip the warning, which is
probably what users want anyway.

Closes #154.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>